home *** CD-ROM | disk | FTP | other *** search
/ SPACE 1 / SPACE - Library 1 - Volume 1.iso / program / 114 / xref2.doc < prev   
Text File  |  1987-10-17  |  4KB  |  92 lines
  1. XREF2.BAS  - A cross-reference utility for GFA Basic,  written  by 
  2. Don Edwards
  3.  
  4.      Given a GFA-BASIC program listing (use the SAVE,A function in 
  5. the editor), for example XREF.LST, it will produce a line-numbered 
  6. listing (XREF.LNM for this example,  unless you specify  something 
  7. else) and a cross-reference file (XREF.XRF), both on disk.
  8.  
  9.      The  .LNM file is just like the .LST file,  except it  has  a 
  10. line  number adding 5 characters to the front of  each  line.  The 
  11. .XRF file is formatted as a report,  with the variable / procedure 
  12. /  label  name  in the first 20 characters of one  line  and  line 
  13. numbers in positions 21-60 of as many lines as needed.
  14.  
  15.      Operation:  I  like fileselector boxes.  So when you run  the 
  16. program,  you  will be given a fileselector box and asked to  pick 
  17. out  a .LST file to process.  (Checking CANCEL will terminate  the 
  18. program.) Once that is done, two more fileselectors let you change 
  19. the .LNM and .XRF files if you like.
  20.  
  21.      Finally,  a  FOURTH  file selector asks you to  identify  the 
  22. DRIVE (and folder,  if you like) for temporary files. In this box, 
  23. the drive and folder are the only things that matter - a  filename 
  24. given  will  be  ignored,  and in fact you don't have  to  give  a 
  25. filename at all! (Just click the OK box.)
  26.  
  27.      I strongly encourage you to put the temporary files on a hard 
  28. disk or RAMdisk,  this program is slow enough anyway. (If you like 
  29. it but think it's too slow, I accept donations to my computer fund 
  30. :-> )
  31.  
  32.      Once that is done,  it prints the names of 4 temporary  files 
  33. (not that you really care, it erases them when it's done) and goes 
  34. to work. Expect messages from the following stages:
  35.  
  36.      Reading the source
  37.      Sorting
  38.      Combining
  39.      Formatting the report
  40.  
  41.      And then it's done! (But don't hold your breath.)
  42.  
  43.  
  44.  
  45.      Hacker's notes:
  46.  
  47.      The  "reading  the source" stage has several things  you  may 
  48. find interesting.  There is,  of course, a stripped-down parser to 
  49. keep track of the current line as it identifies and gathers words, 
  50. but throws away numbers, quoted strings, and other things. You may 
  51. want to take a look at the character-input routine,  which uses  a 
  52. 10K buffer,  and the "skip-the-rest-of-the-line" routine (used for 
  53. remarks  and  data statements) which has to  cooperate  with  that 
  54. buffer.
  55.  
  56.      Once a word is identified, it may be a BASIC keyword which we 
  57. don't  want  to include in the cross-reference.  A list  of  BASIC 
  58. keywords  is included into the program (in  DATA  statements,  but 
  59. it's  read into an array) and a binary search is used  to  quickly 
  60. look through the nearly 250 entries.
  61.  
  62.      The   XREF  program  listing  comes  out  with   nearly   500 
  63. references,  and there are larger programs.  So the references are 
  64. written to a temporary file,  and the sort phase is a 2-way merge. 
  65. This is a useful sorting technique for large files; sort temporary 
  66. files (including the final output file) typically take a bit  over 
  67. twice as much space as the input.  In this case,  the input can be 
  68. discarded  after  the  first  sort  pass.  For  the  theoretically 
  69. inclined,  a  merge sort is among those which achieve  theoretical 
  70. peak performance - in practical terms,  a 3-, 4- or more-way merge 
  71. would be faster (as it would also be if the program kept more than 
  72. two  records  in memory at one time) but would also be  harder  to 
  73. program.
  74.  
  75.      The  only fancy thing about the combining stage is  that  the 
  76. line  numbers,  treated  as numbers in the sort,  are  treated  as 
  77. strings and concatenated together with intervening spaces.
  78.  
  79.      The  report phase is worth a bit of attention for  those  who 
  80. haven't written reports (I've written too many,  mostly in Cobol - 
  81. blech!). An interesting touch is how the concatenated line numbers 
  82. are  spread  out  to be right-justified  in  5-column  fields.  An 
  83. indicator points to the leftmost digit of the number;  from  there 
  84. Ie search for a space (or the end of the string), find the length, 
  85. and use the VAL function to extract the number for a PRINT  USING. 
  86. Then the indicator is advanced.
  87.  
  88.      Nothing really fancy,  just a lot of nitpicking details  that 
  89. have to all be right.
  90.  
  91.  
  92.